Conversation
|
If you run cap staging cloud:status, what do you get back? |
My stage files look like: Not sure that's the best way of driving config for stages with capify-cloud, but it works well enough. Would be nice to be able to just override certain params per stage as most of my cloud.*.yml files have just one line changed |
|
I've been giving it a fair bit of thought, and have come to the conclusion that there are bits of your pull request I like, and some I don't. Let me know what you think. If you're happy to update and submit the new pull request, I'd be happy to include it. --Noah |
Refactor to use guard clauses rather than nested conditionals
|
Sorry for the delay in updating this pull request, but finally got back to it. I've put the original behaviour back in as a fallback and switched it over to guard clauses. The new behaviour and the exception are tested, however the reason for the PR is that the old behaviour doesn't work for me, so I've been unable to test it, however it only differs by one line and I've just put it back in from prior to my first commit. Cheers |
Grabbing the server argument based on position doesn't work when multistage is enabled as the stage precedes the task, e.g.:
This means that the code picking up the argument based on position sees 'cloud:ssh' as the instance id, instead of '1'.
This patch changes to a named argument, e.g.:
This will work regardless of the number of arguments and using the argument cloud_instance should minimise the risk of collisions with other capistrano plugins.